It is now commonplace for users of data processing systems to instruct such systems by means of commands entered in a high level language (H.L.L.). These H.L.L. commands are then converted by the system into a low level language (L.L.L.) set of instructions which the system can understand directly and act upon. For example a particular H.L.L. command may instruct the system to operate a L.L.L. subroutine so as to generate sets of data, hereafter referred to as `objects`, for reference by subsequent H.L.L. commands. Each object is stored in a memory location within an area o memory, hereafter referred to as an object memory, that has been allocated to the L.L.L. subroutine. Subsequently these objects can be retrieved, either directly or indirectly, by means of appropriate H.L.L. commands. This procedure is particularly useful in the area of computer graphics where L.L.L. graphics subroutines are used to generate particular graphical objects under the control. of a program written in a user-friendly H.L.L.
A series of H.L.L. commands can be strung together by a user to generate a H.L.L. user program. A first program, comprising both the user program and a run-time environment, can then be initiated. During the running of the first program, interaction with a second program, including the L.L.L. subroutine, an object memory and an object manager, may be necessary. The L.L.L. subroutine within the second program may be instructed to generate many objects. As the objects are produced and stored in the object memory they will be referenced by particular `slots` in the first program. The term `slot` is used here to refer to any location of storage allocated to the first program, and may for example accommodate a variable or a field within a record.
During the operation of the first program several of these objects may in fact become redundant as the references to slots are redefined by the user program. As an example, consider the following sequence of instructions that might form part of a user program:
INSTRUCTION 1 a:=sphere (1); PA0 INSTRUCTION 2 a:=cube(2); PA0 INSTRUCTION 1 a:=sphere (1); PA0 INSTRUCTION 2 b:=a; PA0 INSTRUCTION 3 a:=cube(2);
The variable `a` is accommodated in a slot allocated to the first program. Instruction 1 will cause the second program to generate an object describing a sphere of radius 1 unit. At this time a reference between this `sphere` object and the slot containing variable `a` will be made. Instruction 2 will cause the same program to generate an object describing a cube of side length 2 units. The reference for the slot containing 1 variable `a` will now be changed so that that slot references the `cube` object. Now that the variable `a` has been redefined as referring to the cube object, the sphere object is no longer referenced by the user program and can be erased by the second program.
However a L.L.L. object cannot always be erased when a slot is redefined in the user program, as the following example will illustrate:
Here the variable `a` has been redefined as in the first example, and so it may appear reasonable for the second program to erase the sphere object so as to free space in the object memory. However the user program variable `b` was set equal to the variable `a` before `a` was redefined, and so `b` still references the sphere object. Thus the sphere object should not be erased at this time.
Hence it is apparent that a problem exists in how to reliably inform the second program that particular objects are of no further use to the first program, so that the second program can decide whether to erase the objects in question in order to free valuable memory space in the object memory for storage of subsequent objects.
Typically the first program will provide means, known in the art as a `garbage collector` for monitoring data resident in H.L.L. memory and erasing such data when it is no longer referenced by the first program. The object manager in the second (low level language) program is less likely to have a garbage collector but may in certain circumstances. For example if the second program contains internal references between the L.L.L. objects in addition to references from the first program to the objects then the object manager will itself include a garbage collector. In this case the object manager will not erase at. object as soon as it is informed that the first program has no further use for that object. Instead the object will only be erased when the L.L.L. garbage collector knows that the first program has lost interest in the object AND the second program has no internal references to the object. For the purpose of the present invention it does not matter whether the L.L.L. object manager has a garbage collector or not.
In the prior art systems the H.L.L. garbage collector runs in its intended manner and erases slots when the first program has no further use for them. However in the L.L.L. the second program runs under the control of the first program, and therefore the L.L.L. object manager must be informed of the circumstances prevailing in the first program before it can reliably erase L.L.L. objects, since it has no means of knowing independently when objects have become redundant. In such prior art systems it has been usual for the H.L.L. user to keep track of the use of all L.L.L. objects generated and explicitly to erase them when they are no longer needed. This has been done by means of a specific instruction from the user to the L.L.L. object manager provided within the system, this command indicating that the first program has lost interest in the object.
Obviously in such simple cases as those illustrated above it is easy for the user to keep track of objects and to free up memory by direct commands when objects are no longer needed. However where complex sharing of the L.L.L. objects within the first program occurs, as for example is the case in many of today's graphical systems, it presents a considerable burden on the system user, and indeed it becomes impractical. for the user to monitor all uses of the objects. The user is forced to use low level programming techniques, such as the explicit programming of use counts, to manage the L.L.L. objects, but this proves to be very labor intensive.